Every FE unit test class pays a full FE startup. Measured on the FE UT CI
agent (build 1008420), that fixed cost is about 54s per class: ~16s of JVM
fork and class loading (measured from test classes that never start an FE)
plus ~38s of FE startup.

210 of the 214 nereids test classes that start an FE finish in under 90s,
i.e. they are almost entirely that fixed cost. Merging classes that already
share the exact same fixture removes it without changing any test.

This first batch merges 12 classes that all extend SqlTestBase and override
no setup at all, so they already ran against an identical fixture (database
"test" with tables T0..T4):

  sqltest/SqlPlanSuiteTest                  <- CascadesJoinReorderTest, InferTest,
                                               JoinTest, MultiJoinTest, SortTest
  rules/exploration/mv/MvExplorationSuiteTest <- BuildStructInfoTest, EliminateJoinTest,
                                               HyperGraphAggTest, HyperGraphComparatorTest,
                                               NullRejectInferenceTest
  rules/rewrite/RewriteRuleSuiteTest        <- PruneOlapScanTabletTest,
                                               EliminateConstHashJoinConditionTest

Test bodies are moved verbatim; method names are unchanged so test reports
keep the same identifiers. Each merged file keeps a "from <OriginalClass>"
section header, so grepping the old class name still lands on its tests.

Verified: 53 tests before, 53 tests after, all passing.

Deliberately not merged here:
- nereids/mv (6 classes): they create materialized views with colliding names
  inside their test methods, so sharing one FE makes them interfere. Needs
  namespace isolation first.
- jobs/joinorder/hypergraph (4 classes): testPullUpQueryFilter exists with
  different bodies in two of them.
- Classes with real work (DistributeHintTest 764s, OtherJoinTest 256s,
  GraphSimplifierConsistencyTest 223s, PreMaterializedViewRewriterTest 205s)
  are intentionally left alone: merging them would create a straggler that
  hurts wall clock under the 12-way parallel CI run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

… 95%

nereids/jobs/joinorder/joinhint/DistributeHintTest was the slowest class in
the whole FE UT suite: 764s in CI build 1008420, 459s in 1008517. The 40%
swing is not noise, the test is unseeded and the amount of work it does
varies per run.

It also had no assertions at all, and never had any since it was added in
apache#28562: mismatches were counted into a field and printed to stdout, so no
optimizer regression could ever fail it. Two of its 182 local seconds were
useful; the rest was enumeration that could not report anything.

Both properties it covers are worth keeping, so the tests are kept and made
able to fail:

- testHintJoin: a distribute hint (broadcast / shuffle) selects a physical
  strategy and must never change the result. This is the only coverage of
  distribute hints over random join graphs. Enumeration unchanged (~910
  optimizations, ~5s); it now asserts.

- testLeading: reordering *inner* joins is always semantics-preserving, so
  any leading order must give the same result as the un-hinted plan. It now
  builds inner-join-only graphs via the existing
  HyperGraphBuilderOld(Set<JoinType>) constructor, draws permutations from a
  fixed seed, and asserts. Enumeration is cut from ~51000 optimizations to
  ~280, which is what made the class slow.

The previous testLeading applied a random permutation to graphs that also
contained outer / semi / anti joins, where an arbitrary leading order is
generally not a valid join order. Asserting on that case fails reproducibly
(3/3 runs, down to 3 tables): extra null-padded rows appear. Whether Doris
should reject such a hint instead of applying it is a question for the
Nereids owners, so that case is kept as a @disabled test documenting the
repro rather than asserting behaviour nobody has decided.

Local runtime: 182s -> 9-10s over three runs, all passing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

26 test classes install a Mockito spy over Env.accessManager (and a few over
systemInfo / authenticationIntegrationMgr) with Deencapsulation.setField and
never put the original back. Each subsequent test method in the same JVM then
spies the previous spy, so the wrappers stack up for the life of the class.

TestWithFeService now captures those three fields once class setup is done and
restores them after every test method.

Capturing after runBeforeAll() rather than before each test is deliberate:
CheckRowPolicyTest installs a spy for the whole class inside runBeforeAll(), so
that spy becomes its baseline and the restore is a no-op there. Capturing
earlier would have torn its spy down after the first test method.

Honest scope note: this was written as a prerequisite for merging spy-using
test classes, but it turned out not to be required for that. Merging six of
them passes with this commit reverted, because each test re-reads the manager
and re-stubs what it needs. What this commit fixes is the unbounded spy
nesting and the latent cross-test contamination, not a failure observed today.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Six classes under nereids/trees/plans/commands each started a full FE to run
two or three validate() assertions with a spied access manager. On the CI
agent that fixed cost is about 50s per class, so the six cost roughly 300s of
test time for 13 assertions.

They are merged into CommandPrivilegeValidationTest:

  AdminRepairTableCommandTest, AdminCopyTabletCommandTest,
  AlterColumnStatsCommandTest, CleanQueryStatsCommandTest,
  ShowQueryStatsCommandTest, ShowTabletsFromTableCommandTest

Members that were byte-identical across the originals (connectContext, env,
accessControllerManager, internalCtl) are declared once. Test methods whose
names collided -- testValidateNormal, testValidateNoPrivilege,
testValidateWithPrivilege and the per-class runBefore() helper -- are prefixed
with their original class, so grepping the old class name still lands on its
tests and the names now say which command they cover.

Two databases had to be renamed. AlterColumnStats and CleanQueryStats both
created a database literally called "test_db", and CatalogMocker.TEST_DB_NAME
is also "test_db", so sharing one FE made the second createDatabase() fail
with "database exists". Each section now creates its own database.

Verified: 13 tests before, 13 tests after, passing on two consecutive runs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>